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Abstract 

We address the question of what software verifica¬ 
tion can do for the audio community by showcasing 
some preliminary design ideas and tools for a new 
framework dedicated to the formal reasoning about 
Faust programs. We use as a foundation one of the 
strongest current proof assistants, namely COQ com¬ 
bined with SSReflect. We illustrate the practical 
impact of our approach via a use case, namely the 
proof that the implementation of a simple low-pass 
filter written in the Faust audio programming lan¬ 
guage indeed meets one of its specification properties. 

The paper thus serves three purposes: (1) to pro¬ 
vide a gentle introduction to the use of formal tools 
to the audio community, (2) to put forward program¬ 
ming and formal reasoning paradigms we think are 
well suited to the audio domain and (3) to illustrate 
this approach on a simple yet practical audio signal 
processing example, a low-pass filter. 
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1 Introduction 

Formal program verification is gaining strong 
support in the computer programming world 
with projects such as the CompCert certified 
C compiler [Leroy, 2009], with more and more 
tools such as the COQ 1 proof assistant striving 
to ease the development of correctness proofs for 
hopefully the every-day programmer. 

While there has been some work in the 
mathematical correctness of DSP — see for in¬ 
stance [Krishnaswami, 2013; Brunei et al., 2014] 
for type-based techniques, and [Souari et al., 
2014; Ghafari et al., 2011] for approaches using 
theorem proving — formal verification is still 
largely absent in the DSP and Computer Music 
(CM) communities. Yet, users and musicians are 
always striving for ever better sound experience 
and audio realism. Thus, ensuring the adequacy 
between an intended audio specification, for in¬ 
stance some sort of a limited-bandwidth filtering, 
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and its actual implementation, along with other 
key properties such as robustness [Chaudhuri 
et ah, 2012] or Bounded-Input Bounded-Output 
(BIBO) stability, is warranted. Too often, the 
only correctness test performed is to check that 
“it sounds about right”, which is a methodology 
that clearly deserves some improvements. 

The overall goal of our paper is to provide 
a case for the introduction of tools and best 
practices dedicated to the formal mathematical 
reasoning about audio/sound application pro¬ 
grams. We illustrate this vision via the use 
of Coq/SSReflect for the Faust audio lan¬ 
guage 2 . We introduce a new framework for math¬ 
ematically reasoning about Faust audio pro¬ 
grams. We show how simple properties can be 
already proven for some FAUST filtering applica¬ 
tions using such an approach, thus paving the 
way to the future introduction of dedicated proof 
techniques for audio processing systems. 

This paper is structured as follows. In Sec¬ 
tion 2, we introduce the COQ proof assistant 
and its SSREFLECT extension, which we use all 
along. Section 3 describes the FAUST language 
core, using a low-pass filter as an example, while 
Section 4 provides a COQ implementation. We 
introduce in Section 5 a specific logic that will 
help reasoning about FAUST programs. We fi¬ 
nally put these tools into good use in Section 6, 
where we show how the low-pass filter can be 
proven equivalent to its specification. We discuss 
future work and conclude in Section 7. 

2 A Coq/SSReflect Tour 

COQ [Bertot and Casteran, 2004] is a software 
development environment in which programmers 
can write functional programs and prove proper¬ 
ties about them. Coq’s programming language 
GALLINA is very similar to other functional pro¬ 
gramming languages like Ocaml, but with some 
added restrictions (in particular, all COQ pro- 
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grams must terminate) and a more advanced 
type system. Coq is a strongly-typed language; 
in particular, a type is understood as a property 
P , and an expression e of type P , written e : P, 
is the proof for P. 

SSReflect [Gonthier et al., 2008] is a proof 
language and extensive library built on top of 
COQ. It promotes a structured style of pro¬ 
gramming and facilitates proof development by 
profiting from the fact that many properties of 
interest can be expressed as programs of type 
boolean. 

Recursive Definitions We will illustrate 
some basics of the SSREFLECT’s proof language 
by proving a toy property over a toy program¬ 
ming language. We first load some required 
libraries: 

Require Import ssrfun ssrbool eqtype ssrnat. 

The Abstract Syntax Tree (AST) of our toy pro¬ 
gramming language is defined in COQ with the 
Inductive command: 

Inductive exp : Type := 

| cst : nat —>exp 

j mul : exp -> exp -> exp. 

Notation "' n" := (cst n). 

Notation "a xb" := (mul a b). 

which declares the recursive (so-called inductive) 
type exp with two constructors, cst for embed¬ 
ding natural integer constants, and mul for the 
multiplication of two expressions. COQ provides 
support to declare convenient notations such as 
x for the multiplication operation. 

Recursive functions are declared in COQ us¬ 
ing the Fixpoint command. Then, the value of 
an expression in our toy language is defined by 
recursion over its structure: 

Fixpoint eval (e : exp) : nat := 
match e with 

| ’ n => n 

j el x e2 => eval el * eval e2 

end. 

We can run our program with the Eval com¬ 
mand: 

Eval compute in eval (’2 x(’0 x ’3)). 

which will display, as expected, 0. Going one step 
further, Ocaml code can be generated automati¬ 
cally from COQ programs, providing reasonably 
efficient and provably-correct implementations 
of the specified algorithms. 

Proving Properties Following upon our pre¬ 
vious simple test, assume we want now to 
prove the following, 0-absorbing property, named 
evalOeB: all expressions e that contain a ’0 


subexpression evaluate to 0. We can write a 
boolean function mem_exp that checks if ’0 oc¬ 
curs in an expression e easily 3 : 

Fixpoint menu exp m e := 
match e with 

’ n => n == m 

el x e2 => mem_exp m el || menu exp m e2 
end. 

Theorem evalOeB is rephrased now as: for all 
expressions e, if mem_exp 0 e is true, then eval 
e is 0. Let’s begin by proving an easier property 
for constant expressions; it is stated here in COQ 
as Lemma evalOeB, followed by its proof: 

Lemma evalOeB : 

forall n, mem_exp 0 (’n) -> eval (’n) == 0. 

Proof, by move=> n /=; exact. Qed. 

In addition to programming in GALLINA, we can 
also use automated program building procedures 
called tactics. We can use an interactive proof 
editor such as Proof General of CoqlDE to step 
from Proof to Qed; after each tactic (terminated 
by a .), the current proof state is displayed. The 
proof state consists of a set of hypotheses e : t 
(the “context”) and a goal g which should be seen 
as a stack of properties po->....->p n ->g. Most 
SSReflect tactics tac can perform context ma¬ 
nipulation operations before and after running, 
tac: x will remove a named hypotheses x : p from 
the context, pushing p to the goal before tac is 
run; tac => x will pop the top of the goal af¬ 
ter tac is run, naming it x. Thus, if po~>A is 
the current goal, move=> x will add x : po to the 
context. Plenty of additional operations can be 
performed in addition to moving. 

The previous proof started with the 
documentation-only Proof command, getting 
the goal: 

forall n, mem_exp 0 (’n) -» eval (’n) == 0. 

with an empty context. The first step is to 
move n to the context with move=> n /=. The /= 
switch asks COQ to perform partial evaluation of 
the goal, resulting in a new goal n == 0 —* n == 0, 
which the exact tactic solves. Finally, Qed 
checks that the proof is correct, and, as for all 
previous function and type definitions, evalOeB 
is added to the global context for further use. 

Moving then to our full theorem, we state: 

Theorem evalBeB : 

forall e, mem_exp 0e-> eval e == 0. 

Proof. 

elim. 

- by apply: evalOeB. 

- move=> el HI e2 H2 /=. 

3 Coq uses type inference to get the types of m and e. 






case/orP=> [/HI | /H2] /eqP . 

+ by rewrite mulOn. 

+ by rewrite mulnO. 

Qed. 

Here, the proof starts by performing induction 
on the structure of expressions. The induction 
tactic elim operates on the top of the goal, which 
in this case is the expression e. The base and 
inductive subgoals are generated, displayed as: 

subgoal 1 (ID 18) is: 

to rail n : nat, mem_exp 0 (’ n) -> 
eval (’ n) == 0 

subgoal 2 (ID 19) is: 

to rail e : exp, 

(mem_exp 0 e -> eval e == 0) —> 
forall e0 : exp, 

(menuexp 0 e0 -> eval eO == 0) -> 
menu exp 0 (e xe0) —>■ eval (e xeO) == 0 

We must prove each goal separately (the - and 
+ symbols indicate a new proof step). The base 
case is dealt with by first using Lemma evalOcB 
from the global context with the apply tactic 
(the by so-called “closing tactical” ensures that 
the current goal is finished). In the inductive 
case, the goal includes the facts that evalOeB is 
true on each subexpression, named here e and 
eO by COQ. We first move e and eO, renamed 
el and e2, to the context, each followed by its 
induction hypotheses H*, before performing a 
partial evaluation. After the move, we have the 
following proof state: 


el 

exp 


HI 

mem_exp 0 el - 

-► eval el == 0 

e2 

exp 


H2 

mem_exp 0 e2 - 

-► eval e2 == 0 


menuexp 0 el | menuexp 0 e2 
eval el * eval e2 == 0 


The top of the goal is a boolean disjunction, 
on which we can perform case analysis using 
the case tactic with the orP view. Each of the 
two resulting cases happen to be the premise of 
the induction hypotheses, HI and H2; thus the 
disjunctive pattern [/ Hl|/H2] will rewrite the goal 
to: 

eval el == 0 -> eval el * eval e2 == 0 

and similarly for e2. The pattern /eqP— >■ will 
rewrite eval el to 0 in the goal obtaining a goal 
of 0 * eval e2 == 0. 

This particular step is paradigmatic of the 
“proof by rewriting” technique: from a property 
a = b, we can replace all a terms occurring in the 
goal by b. The final step of the proof is again by 
rewriting, this time using the mulOn and mulnO 


lemmas part of the ssrnat library, with type 
mulOn : forall x, 0 * x = 0 and symmetrically. 

Rewriting Magic SSReflect’s emphasis on 
boolean expressions fosters proof by rewriting in 
arithmetic proofs. For instance, in the following 
lemma: 

Lemma leq_2add : 

forall (x y : nat), x <= y -> x + x <= y + y. 

Proof, by move=> x y xy; rewrite leq_add. Qed. 

the proof, where “;” combines proof steps, is done 
by rewriting with the leq_add lemma, provided 
by the ssrnat library, of type: 

leq_add : forall (ml m2 nl n2 : nat), 

ml <= nl —>• m2 <= n2 ^ ml + m2 <= nl + n2 

How could that happen? Equalities do not seem 
to occur in the conclusion of leq_add, but they 
have actually just been removed by the pretty 
printer. In fact, the exact conclusion is a boolean 
equality, namely ml + m2 <= nl + n2 = true, as 
the resulting type of the <= operator is 
boolean. Thus, x + x y + y = true can be 
easily matched and rewritten to true with proper 
bindings of leq_add variables, leading to the goal 
true = true. 

Going Further It is obviously impossible to 
give a complete overview of SS REFLECT in two 
pages. In particular, SSREFLECT advocates par¬ 
ticular conventions and coding styles that we 
did not fully follow for the sake of space and 
pedagogy. In particular, the idiomatic proof for 
Theorem evalOeB is: 

by elim=> //= ? IH1 ? IH2 /orP 

[/ IH1|/IH2] /eqP —>; rewrite ?(mul0n, mulnO). 

The Mathematical Components library is a com¬ 
panion project to SSReflect, and includes 
extensive libraries about finite groups, algebra, 
number theory and more, which have been used 
to formally prove significant large theorems like 
the Four Color or Feit-Thompson theorems. 

3 The Faust Audio Language 

Faust— which stands for “Functional Audio 
Stream” — is a DSP language [Orlarey et al., 
2004]. Faust’s main focus is the fast develop¬ 
ment of efficient digital audio programs, and has 
been used in live performances and offline and 
online audio applications, such as FaustLive [De- 
noux et al., 2014] or moForte 4 . It has also been 
used in other signal processing contexts [Barkati 
et al., 2014], 
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Framework FAUST programs are structured 
in two layers. The high-level layer is a macro lan¬ 
guage corresponding to an untyped, full-fledged 
functional language. It is used to generate pro¬ 
grams written in the Core FAUST syntax, where 
only a few primitives are available. In order 
to deal with the real-time constraints imposed 
by audio processing, Faust programs are then 
optimized and compiled towards an efficient lan¬ 
guage; Faust’s main compiler generates C++ 
code, while alternative backends can now gener¬ 
ate other formats, such as asm. js code. 

While the core language is unpractical for writ¬ 
ing real applications, it contains enough prim¬ 
itives for the rest of this paper. Moreover, it 
enjoys a strong type system and operational se¬ 
mantics. For a more precise description of FAUST 
syntax and semantics, we refer the reader to [Jou- 
velot and Orlarey, 2011]. 

Semantics Signal processors are Faust’s key 
components. A signal is a (potentially infinite) 
stream of amplitude values. In the discrete case, 
we can represent signals as functions from (dis¬ 
crete) time to real numbers. Formally, we write 
S for the function space N —> M. We assume that 
signals have amplitude 0 when time is negative. 
Signal processors from i inputs to o outputs are 
functions in §* —> §°, and every valid FAUST 
program can be interpreted as a function of this 
type. We use “semantics brackets” to denote 
the function that maps a FAUST program to its 
mathematical interpretation. For instance, the 
delay processor, which delays its input signal by 
1 audio sample, is denoted as: 

[delay] (i)(n) = i(n - 1). 

The first argument i is the signal to be delayed, 
and n represents time. Then, delay will simply 
return the sample from i corresponding to the 
previous time value. 

Core Faust For the purposes of this paper, 
we focus on a minimal but functional subset 
of Faust consisting of three particular signal 
processor-building blocks: primitives, composi¬ 
tion, and feedback. 

Examples of primitive signal processors are +, 
which takes as input two signals and outputs a 
signal with amplitude the sum of the input signal 
amplitudes, or *(c), that scales the amplitude by 
a constant factor c. Formally: 

[+K*iA 2 )(n) =i\(n) + i 2 {n) 

K<0](ii)(n) =c*h(n). 


r process 



Figure 1: Simple Feedback in FAUST 


We write f : g for the composition of signal 
processors f and g: 

If : d(0 = Isl(I f 1W)- 

The interesting construction is feedback, writ¬ 
ten as f ~ g. In this case, f is assumed be a 
processor from two signals to one, and g, a unary 
signal processor. Then, f ~ g represents the 1- 
delay feedback loop through g. 

[f ~ g](i) = [f]([gK([ f ~ g] ([delay] (»))),*). 

Note that the definition of the semantics of feed¬ 
back is recursive. For example, the FAUST pro¬ 
gram -\ — sin is depicted in Figure 1. 

A Simple Low-Pass Filter For the rest of 
the paper, we will work with a simple low-pass 
filter written in FAUST as: 

smooth(c) = *(1 - c) :+ ~*(c). 

smooth is intended to be used with a coefficient 
c in the interval [0,1]. If c is 0, then the filter 
has no effect, whereas as we increase c the cutoff 
frequency decreases, with a limit case of c = 
1, that outputs a constant signal. The filter 
first multiplies the input amplitude by 1 — c, 
then to perform 1-sample additive feedback with 
coefficient c. Its block diagram with c = 0.9 is 
drawn in Figure 2. 

While this filter may not be very adequate 
for audio, due to its frequency response curve, 
it is useful for instance for smoothing control 
parameters, and for other applications with high- 
frequency components. A key property of filters 
is stability. That is to say, we expect smooth’s 
output amplitude to remain in bounds that de¬ 
pend on the input. An excessive amount of 
feedback could cause the filter to behave badly. 
























Figure 2: The smooth Low-Pass Filter 


Stability also helps in compilation, as bounds 
known in the input signal can be propagated to 
the output, helping with buffer allocation and 
other issues. 

4 Formalizing Faust in Coq 

In the previous section, we described a core sub¬ 
set of Faust on paper. In this section, our goal 
will be to replicate this description inside a mech¬ 
anized framework, COQ. This will enable us to 
later mechanically reason about FAUST programs, 
avoiding a lot of potential error sources and get¬ 
ting strong confidence on the soundness of our 
reasoning. 

Overview Mechanized reasoning about pro¬ 
grams requires to encode their behavior or seman¬ 
tics in the particular theorem prover of choice. 
In a sense, this is equivalent to defining an in¬ 
terpreter ; however the idiosyncrasy of theorem 
proving often makes the process quite different 
from writing a regular interpreter or compiler for 
our language. 

Once the semantic representation is in place, 
we can wonder whether two programs have the 
same behavior (read: semantics), what happens 
when the input does not meet certain criteria, 
etc. 

The concrete tasks we need to complete in 
order to start reasoning about FAUST programs 
in COQ are: a) define a representation of FAUST 
syntax in COQ; b) define a representation for 
signals, or streams, in COQ; c) write a function 
that takes a program’s AST and returns a stream 
processor. 

Once this is done, we can start proving! How¬ 
ever, a key point in theorem proving is how con¬ 
venient will it be to write proofs. We would 
have a hard time justifying formalized reason¬ 


ing if we needed thousand of hours and lines 
of proof to perform trivial reasoning. We will 
address this point in Section 5, while devot¬ 
ing the rest of this one to explain how FAUST 
is embedded into Coq. All the Coq code 
and examples can be downloaded from https: 
//github.com/ejgallego/mini-faust-coq/. 

Faust AST in Coq We will encode the syn¬ 
tax of the program using an algebraic or inductive 
data type. ADT (Abstract Data Types) are one 
of the most powerful features of COQ, allowing 
the user to define new richly-typed datatypes. 
In Section 2, we saw an example of an ADT for 
expressions. Here, we will make use of an extra 
feature known as indexed or dependently-typed 
ADT. Thus, we will encode Faust expressions 
using the fterm datatype, which carries addi¬ 
tional information about the number of input 
and output signals of the program: 

Inductive fterm : nat -> nat -> Type := 
mult : num -» 1 
plus : 2 1 

comp : l 1— 

feed : 2 i -> 1^1 ->i^i 

where "i «o" := (fterm i o). 

Notation "'+" : = plus. 

Notation " (c)" := (mult c). 

Notation "f : g" := (comp f g). 

Notation "f - g" := (feed f g). 

Thus, a program of type i o will exactly go 
from i to o channels. Note that the constructors 
that correspond to the primitives enforce this 
requirement. In particular two signal processors 
can be composed only if they have the right 
types; thus no ill-typed Faust program can be 
built. We also define some notations to make 
display nicer. 




























Now, we can define our simple low-pass filter 
as follows: 

Def smooth c : 1 •wl — ’*(1 - c) : ~ ’*(c). 

Streams in Coq Once we have defined the 
syntax of our FAUST programs, the next step is 
to define their semantics. We will encode signals 
as finite-length sequences of reals. We could 
have used several other representations, but it 
is beyond the scope of this paper to discuss the 
advantages of this particular definition. 

We will index signals by their length, using 
the SSReflect type n.—tuple R, the type of 
sequences of exactly n reals. We write ’S_n for 
n. — tuple R to shorten notation. Signal proces¬ 
sors are encoded using regular COQ functions: 

Notation " ’S_n" := (n.-tuple R). 

Notation " ’SP(i,o)" := (V n, ’S_rri -> ’S_rro). 

For instance, the type for signals with three 
samples is ’ S_3. A signal processor (of type 
"'SP(i,o)") must be able to process signals of 
arbitrary length; thus we quantify the second 
definition on all lengths n. We write ’S_rrk for 
k copies of ’ S_n, e.g., ’ S_n~2 is (’ S_n * ’S_n). 

Interpretation Function With both syntax 
and semantics in place, we can define a function 
linking the two worlds. In our case, a FAUST 
expression of type i o will be interpreted by a 
Coq function of type V n, ’S_rri -> ’S_rro. Our 
interpreter I will thus have type: 

I : i -w o -> ’SP(i, o) 

Given a program f, the resulting function I f 
is effective, that is to say, given input signals, it 
computes the corresponding output ones. In par¬ 
ticular, I f n formally corresponds to the seman¬ 
tic brackets introduced in Section 3, restricted 
to the first n samples of the signal. We write 
I/] |n f° r this truncated semantics. 

How is I defined? Definition for primitives 
and composition is straightforward; the most 
interesting case is the feedback: 

Definition I_feedback f g n i := 
iter n (fun fb f (g (x0 :: fb), i)) [::]. 

where x0 is the initial value for the feedback 
loop, usually 0, and iter n f x is the function 
that applies f n times to x. 

Note that this function outputs a signal of size 
n when the input is of size n, and does so by 
computing the feedback for n steps. The reader 
familiar with signal processing will notice that 
this implementation is extremely inefficient, as 
it may take quadratic time even for simple pro¬ 
grams! Indeed, the goal of our interpretation is 


not to achieve efficiency, but to have a convenient 
representation of the semantics in order to reason 
about it. Usually, efficient implementations are 
not very well-suited for reasoning and vice-versa. 
The usual remedy when we care about efficiency 
inside COQ is to define two implementations, and 
prove them equivalent [Denes et al., 2012], 

First Steps in Proving With those ingredi¬ 
ents, we can start reasoning about programs. For 
instance, a proof of the fusion property of the 
multiplication stream processors is: 

(* Fusion of mult *) 

Lemma multF : I (’*(a) :’*(b)) - I (’*(a*b)). 

Proof. 

apply: val_inj; case: i => s /= _. 

by elim: s => //= xs->; rewrite mulrCA mulrA. 

Qed. 

The proof is straightforward, by induction, as¬ 
sociativity, and commutativity of the multipli¬ 
cation operator of the real numbers. However, 
some amount of boilerplate is necessary to set 
up the induction, task that can get tricky with 
more complex programs. Indeed, this inductive 
proof method is common to most proofs; thus 
we will identify common patterns and will define 
higher-level reasoning principles that allow us to 
prove things with less effort in the next section. 

5 Structured Reasoning: A Sample 
Logic 

As we just saw in Section 4, the COQ semantics 
allow us to state — and attempt to prove - 
almost any property imaginable about FAUST 
programs. However, in most cases, reasoning can 
be repetitive, long and error-prone. That is the 
price we have to pay for accessing such a power. 

A key observation is that proofs of certain 
classes of properties share common parts, while 
only a minor part of the proof actually depends 
on the property. As we saw in the previous fusion 
case, the relevant part of the proof is less than 
10% of its total code. 

Imagine a property tp, supposed to hold for all 
samples of a signal. Then, it is enough to define 
p as a predicate over one sample, and we can 
“automatically” lift the predicate over signals, 
checking that p holds for all time. 

Indeed, to illustrate the principles of high- 
level structured reasoning over programs, we will 
focus on such “sample-level” properties in this 
section. While we will sacrifice quite a bit of 
expressivity, by limiting our language to one- 
sarnple statements, this will still be enough to 
carry out proofs of stability and will significantly 


facilitate our proofs, allowing us to proceed in a 
short and structured way. 

Sample-level Properties For our purposes, 
a predicate over a sample is a function from 
reals to booleans, <p, ip e M —> B, or, in Coq, 
P, Q : R -> boot. Then 5 , we say a property f 
holds for a signal s if Vn.y?(s[n]); that is, for 
all time moments n, the sample meets f. In 
COQ, we can use the all function for sequences, 
thus writing all P s. For instance, the prop¬ 
erty that a signal is bound by the interval [a, b] 
is defined as f(x) = x e [a,b], or in Coq as 
P := fun x => x \in ‘[a,b). 

It makes sense to extend our properties to sig¬ 
nal processors. In this case, we would like to 
relate properties over input signals with proper¬ 
ties over the output signals. Given sample-level 
properties (f, ip) and input and output signals 
(i,o), a reasonable statement could be: “if the 
input signal i satisfies f, then o should satisfy 
iff.” 

If we think of our previous “being in an interval” 
property, its extension to signal processors allows 
us to capture stability. Indeed, we can precisely 
state now: “if the input signal is bounded, then 
the output signal will be too.” 

Judging the Sampling The previous relation 
between input and output signals and their prop¬ 
erties constitutes an instance of a “high-level” 
reasoning principle. It is highly convenient thus 
to encode the fact that a signal processor satisfies 
the property as a “judgment.” Our judgments 
will be of the form, {</?} / {ip}, with intended in¬ 
terpretation [[{</?} / {ip}} such that, for all input 
signals with samples satisfying f, all the output 
samples of / satisfy ip. Formally: 

IM / IV’}] 

V*.(Vt.v?(i(t))) (Vi,^([/])(i)(t)) 

the COQ version is expressed in a slightly differ¬ 
ent way, using all: 

Definition ’[[ { P } f { Q } ]] := 

V n (i : ’S_n), all i P ==> all (I f n) Q. 

In the case of i input and o output signals, judge¬ 
ments are extended pointwise to use one predi¬ 
cate per signal: ...,fi} f {f \,... ,f 0 ]\- 

Reasoning Rules Now, we’d like to have a 
system of rules to determine when a judgment is 
valid without resorting to analyzing its seman¬ 
tics. 

s From now on, we will interchangeably use Coq and 
mathematical notation where no confusion can arise, omit¬ 
ting double definitions. 


The standard way to achieve this goal is to 
introduce a “logic”, or a set of rules to infer 
validity of judgments, and, by extension, of their 
intended properties. The form of a rule is 

Ai ... A n 

B 

meaning that, if A \,..., A n are valid, then B also 
is. This way, we can hopefully reduce validity 
checking for B to smaller problems. 

The rules of our particular system for sample- 
level reasoning are shown in Figure 3. Rule Prim 
is an example of a base rule, stating that a judg¬ 
ment about a primitive is valid if its semantics is. 
Rule Comp allows to reduce the verification of 
composition to the verification of its individual 
parts; a judgment about composition is valid if 
there are valid judgments about the individual 
signal processors such that the property of the 
output of / implies the required property for the 
input stream of g. 

The Feed rule is quite similar to the compo¬ 
sition rule: the internal state of the feedback 
should obey an invariant 9, and samples from 
the feedback output should be compatible with 
the requirements of c/’s input. We also require 
that the initial value xq satisfies ip. 

Now, all that remains is to check that the 
rules are sound, that is to say that validity of the 
premises implies the validity of the conclusion, 
and we can reason using the newly defined logic: 

Theorem 5.1 (Soundness). For any program f 
of type i o, if {fx ,..., fi} f {ip u ...,ip a } is 
derivable, [{<£>i,... ,fi} f {ipi,... ,ipo}} is valid. 

Proof. We proceed by induction on the deriva¬ 
tion. The base case is the Prim rule, and proof is 
immediate. For Comp soundness automatically 
follows by induction hypotheses. For Feed, we 
apply induction on the length of the input signal, 
plus induction hypotheses. □ 

6 Case Study: Filter Stability 

As a case study, we will verify that the smooth 
filter of Section 3 is stable, that is, if the input 
amplitude is bounded, the output amplitude is. 

Assume a well-formed interval [a, b ], including 
0, and c e [0,1]. In COQ: 

Hypothesis (Hab : a <= b). 

Hypothesis (H0ab : 0 \in ‘[a, b]). 

Hypothesis (Hrc : c \in ‘[0, 1]). 

then, we will prove: 

{i e [a, 6]} smooth(c) joe [a, &]} 






+ i 2 (t))) 


W) f {6} {6>} g {ip} 

{ip} f -.g {ip} 


{iPl,iP2} + {ip} 
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Prim 

H V’(^o) {0,<p} f M W 9 {8} 
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Figure 3: A simple logic for FAUST program verification 
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{lab} *(1 - c) {I a bc} 


{labci Iabc} A {Iab } {lab} *(c) {Iabc} 

{Iabc} + ~ *(c) {lab} 


with: 


Iab{x) sie[a, b] 


{i e [a, b ]} *(1 — c) : + ~ *(c) {o e [a, b ]} 

Iabc(x) = X e [a* c,b* c] I a bc{x) = x e [a * (1 - c), 6 * (1 - c)] 


Figure 4: Derivation for smooth 


Let us recall the definition of smooth: 
smooth(c) = *(l-c) : H—*(c) 

then, we should apply rule Comp , with 0(s) = 
s e [a * (1 — c), b * (1 — c)]. Using Prim gets us 
to a first obligation, shown in Coq as: 

Hi : i \in ‘[ a, b] 

i * (1 - c) \in ‘[(a * (1 - c)), (b * (1 - c))] 

which can be proved using the libraries by: 

by rewrite ?itv_boundlr /= ?ler_wpmul2r 

?ler_subr_addr ?add0r ?Hrc ?(itvP Hi). 

The next step is to apply Feed, choosing 
9{s) = s e [a * c,b * c]. Then, we apply Prim 
twice to get the obligations for + and *(c): 

HI : il \in ‘[( a * c), (b * c)] 

H2 : i2 \in ‘[(a * (1 - c)), (b * (1 - c))] 

il + i2 \in ‘[a, b] 

solved by: 

have Ha: a = a * c + a * (1 - c) 

by rewrite -mulrDr addrC addrNK mulrl. 
have Hb: b = b * c + b * (1 - c) 

by rewrite -mulrDr addrC addrNK mulrl. 
by rewrite itv_boundlr /= Ha Hb 

! ler_add ?(itvP HI) ?(itvP H2). 

where have introduces a local lemma, and 
Hi : i \in ‘[ a, b] 

i * c \in •[( a * c), (b * c)] 
solved by: 

by rewrite itv_boundlr /= 

?ler_wpmul2r ?(itvP Hi) ?Hrc. 


We have chosen to prove the arithmetic obliga¬ 
tions manually, but we should remark that there 
exists tools that can prove this kind of results 
automatically. The full derivation is in Figure 4. 

7 Conclusion 

We presented a case for the use of developer- 
assisted formal reasoning tools in the field of 
computer music and, more generally, audio DSP. 
We gave a quick tour of the COQ/SSREFLECT en¬ 
vironment, which we believe can be particularly 
well fitted to reach such a vision. We applied our 
approach to the FAUST audio signal processing, 
providing a formal semantics for its core and 
detailing how a property of a filter can be proven 
using a specific logic designed for Faust. 

Future work will tackle other applications in 
the audio processing domain to assess our tool, 
together with the development of specific DSP 
mechanisms within Coq/SSReflect (tactics, 
tacticals, or even a dedicated DSP library). We 
would also be interested in seeing how our sys¬ 
tem can be of help to prove more foundational 
theorems such as the Shannon Sampling Theo¬ 
rem. 
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